home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / mint / mgr / sparcmgr / demo2.zoo / demo / ex / TODO / text0002.txt < prev    next >
Encoding:
Text File  |  1984-06-11  |  6.3 KB  |  116 lines
  1. 29/7/83
  2.     I got a reply from Horton: a copy of my (first) letter,
  3. annotated with comments that this should indeed be fixed, that
  4. would be impossible, etc..  I'll send a copy to anyone who'd
  5. like (or a copy of his comment on some specific bug they're
  6. interested in).  Meanwhile, I'll send you my reply to him, since
  7. it discusses still more bugs and possible improvements.
  8.  
  9. Dear Mark,
  10.      Got your comments on my first letter!  Did you get the second,
  11. shorter one?  Glad to see that some things, at least, can be fixed.
  12.      Robert has put version 3.9 on this machine and I'm using it.
  13. Using movement arrows within insert mode is amusing; though when there
  14. is documentation, there should be a warning to the user that these
  15. prevent ``u'' from undoing anything before those commands.  But
  16. the first thing there needs to be documentation for is vedit!  Is
  17. any being written?
  18.      In your comment on ``Can't yank inside global/macro'' you said
  19. that one can, of course, always yank to a named buffer.  I checked,
  20. in the case of @a scripts, and the answer is yes and no:  The yank
  21. works, but one still gets that diagnostic, and anything else in the
  22. sequence of commands is aborted.
  23.      And concerning the diagnostic ``Can't undo in global commands'' --
  24. I understand what you say about why one can't, but it still seems an
  25. unenlightening and perhaps inappropriate diagnostic to get when one has
  26. done  @a  and buffer  a  contains say
  27.     x:g/foo/s//bar
  28. Here the initial ``x'', deleting the character the cursor was on when
  29. the command was given, creates the text-modified condition which,
  30. as I mention, seems to cause globals in @-scripts to give this
  31. diagnostic.  I've just tested the above script -- several times,
  32. because I found it hard to believe what was happening -- and it did
  33. indeed give the diagnostic in question, but instead of replacing foo's
  34. with bar's, it replaced the first line containing a foo with a copy of
  35. the last line of the file! I leave it to you to figure that one out!
  36. (This is on version 3.9.  Incidentally, I've used a true ^M in that
  37. script, so it is ready for you to try.)
  38.  
  39.      Further observations on some of the bugs I mentioned in my
  40. second letter:  The business with  yb  is both more general and more
  41. complicated than I realized.  The general fact seems to be that when
  42. one does a yank to a position earlier on the same line, the cursor does
  43. not move, but the editor thinks it has, so that any subsequent command,
  44. e.g. a movement, a delete, etc., has the effect that it would if it had
  45. been done with the cursor starting from the new position.  The
  46. complication is that yanks to named buffers don't behave the same as
  47. simple yanks: They also leave the cursor unmoved, but what they actually
  48. yank into the buffer is the text from the cursor location to the end of
  49. the line; and whether they cause the editor to consider the cursor to
  50. be in a different location from where it really is seems to depend on
  51. the movement in question:  with "ayNb, no, with "ayN|, yes (where N
  52. again stands for a positive integer).  So what I called a snake in the
  53. grass seems to be a can of worms!
  54.      In experimenting with this, incidentally, I've found that, while a
  55. put from a named buffer can be undone with u, if one attempts the
  56. command U, ``undo all changes made since coming onto this line'', only
  57. changes made since the last named-buffer-put are undone.
  58.  
  59.      I mentioned various abbreviations that were hard to unabbreviate,
  60. but could be done with the help of ^V -- but that I had found no way
  61. to undo
  62.     :ab if if\pq
  63. To be precise, I had found that  :una ^Vif,  :una ^V^Vif,  and
  64. :una    ^Vif  where each ^V represents two ^V's typed in, didn't work.
  65. I've finally found something that does:  :una i^Vf.
  66.  
  67.      I find the diagnostic ``No tail recursion'' strange,
  68. since the occurrence of an abbreviation at the end of the item
  69. abbreviated shouldn't cause a recursive loop; while circumstances that
  70. do cause such a loop, namely the occurrence of the abbreviation within
  71. the item abbreviated, preceded by a space and followed by punctuation,
  72. are not censored, e.g. :ab x ( x ), or with more subtle effect,
  73. :ab x x sup 2.
  74.      It seems that if one has :ab x word,  then the abbreviation works
  75. when x is preceded by a beginning-of-insert, a space, a tab, or a
  76. newline, and followed by most any nonalphabetic character.  For
  77. word-processing use, it would be natural to allow it to also be
  78. preceeded by (, ", `, [, perhaps even a user-specified set of
  79. characters.
  80.  
  81.      To my list of vi commands which I think should be able to take
  82. counts, add p and P.  I often want to put in a large number of copies of
  83. one or more lines, as ``forms'' in which I will enter various kinds of
  84. additional data, and it would be convenient to be able to do compose
  85. such a line and then duplicate it the desired number of times all at
  86. once.  What I currently do is produce a copy and then go
  87. yypk2yypk4yyp... till I have enough.
  88.  
  89.      Two more commands I think would be useful:  (1) One which "puts" to
  90. the screen (in the sense of g/pattern/p, i.e. without affecting the
  91. buffer) the contents, or the first lines in cases that are longer than
  92. one line, of all nonempty buffers, named or numbered, with an
  93. indication, of course, of which each was.  (Ideally one would like to
  94. be able to specify some subset of the buffers, whether one wants the
  95. first line, or everything, or some specified number of lines, etc..) 
  96. (2) One which would show the script of the command stored to be used as
  97. ``.''.  (And perhaps ditto with the last search pattern.)
  98.      Oh, yes: it would also be nice to have a way to give commands
  99. without having them displace the one specified to be repeated by ``.'',
  100. e.g. if one wants to do a certain change time after time at various
  101. points in the file (using ``n'' and ``.'') but occasionally sees other
  102. changes to be made along the way.  An alternative to the above would be
  103. a way to read the command stored to be used as ``.'' into a named
  104. buffer, so that one can give other commands and then return to
  105. that one.  This would also allow one to reread the text of the command:
  106. useful if it isn't behaving as one meant it to.
  107.      
  108.      You might as well send any future mail to me here as
  109. gbergman@cartan -- I was using brahms while cartan's terminals were
  110. being moved but I'll probably be using cartan more from now on.  But
  111. I'll check mail on both.  (However, I'll be on vacation in New York
  112. State from the 3d to the 16th of August.)
  113.                         Best regards,
  114.                         George
  115.  
  116.